As is well known in the computer-related arts, software code is often improved resulting in additional versions, also know as updates, of the same that are backwards compatible with existing physical computer architectures designed to facilitate executing the same. Often several versions of software code occur during computer architecture development and many may occur after computer architecture has been placed in operation by an end-user, e.g., customer. The intended purpose of computer code updates is to improve the overall function of the architecture and, at times, increase the operational life of the same. As a result, reliably and efficiently providing software code updates is important in both the development and operation of computer architectures.
For example, a common impetus for generating software code updates is to ameliorate, if not obviate, problems, often referred to as “bugs”, with existing software code. Another impetus for generating software code updates is to provide existing computer architecture with additional functionality or improved functionality of an end-user-specific task. One drawback with providing software code updates is the risk of the occurrence of code corruption. Code corruption may result from a myriad of causes: operator error, power failure during update and the like. Code corruption may either result in either patent or latent functionality problems. For example, the computer architecture may become inoperative due to code corruption. Alternatively, the computer architecture may appear to be operating correctly and produce erroneous results or may produce a time-delayed patent problem, e.g., become inoperable some time after the update occurred. Therefore, there have been prior art attempts to avoid the problems associated with code corruption.
FIG. 1 describes a prior art attempt to ascertain the existence of code corruption that includes comparing the value of a segment of a software code update with a predetermined value and comparing the same with an expected value. At function 100, the code is downloaded to an embedded device (not shown). At function 105, a previously downloaded byte is read from the embedded device (not shown). At function 110, the byte is compared to the expected value. At function 115, a determination is made regarding whether the byte value matches the expected value. At function 120 an indication that the code is corrupted is made if the byte value does not match the expected value and the process ends at function 135. If the byte value matches the expected value, at function 125 a determination is made regarding whether there is another byte to check. This process continues until all bytes in the program have been checked. Were all of the bytes checked and determined to match their expected values, an indication that the program is valid occurs at function 130.
Referring to FIG. 2, a prior art method of overcoming the existence of corrupted code is described as including redundant copies of the same in a memory space (not shown). At function 301 the software code update is downloaded into the memory space (not shown). At function 305 differing copies of the program are stored in differing addresses of the memory space (not shown). For example, a first copy of the program code is maintained in a first set of addresses in the memory space (not shown) referred to as main flash memory (not shown). An additional copy of the program code is maintained in a second set of addresses in the memory space (not shown) referred to as boot flash memory (not shown). At function 310 execution of the program code commences in boot flash memory (not shown), and at function 315 a determination is made regarding whether code stored in the main flash memory (not shown) is corrupted. Were the program code stored in the main flash memory (not shown) corrupted, the copy of the program code stored in the boot flash memory (not shown) is executed at function 320. Were the program code stored in the main flash memory (not shown) not corrupted, a copy of the program code in main flash memory is executed at function 325. A drawback with this recovery technique is that at least twice the amount of memory space is required to provide recovery. In addition, were the program code in both main memory and boot memory corrupted recovery would be problematic.
A need exists, therefore, for an improved technique to overcome the drawback of code corruption.